The present invention relates to an end-to-end test and diagnostic manager for testing components and diagnosing service problems for services delivered via layered, multi-domain network environments.
In the past, various telecommunications services such as voice communication, data services, video services, and the like were delivered via stand-alone vertical networks. For example, FIG. 1 shows separate distinct networks for delivering voice communication services and applications 10, data services and applications 12, and video services and applications 14. Each separate network includes a service layer 16, control and switching layer 18, transport hardware layer 20, and a physical network layer 22. In each case the services are tightly coupled to the physical networks and network elements provided for distributing the services. For example, in a public switched telephone network (PSTN) the control and switching protocols and the physical switches themselves are all geared toward creating end-to-end circuits for providing point-to-point voice communication. Similar dedicated networks such as Ethernet, token ring, and the like having their own switching and control protocols and physical transport structures were developed for providing data transmission services. Video services, either broadcast or delivered via broadband cable, likewise developed their own set of control and switching protocols, transport hardware and networks. In each case, all aspects of the various integrated networks were configured specifically for the particular service the networks were designed to deliver.
Troubleshooting service problems in the vertically distributed proprietary networks of the past was a fairly straightforward proposition. The entire network was typically owned and controlled by a single entity having intimate knowledge of the end-to-end service delivery chain. This and the fact that the services were so tightly coupled to the network elements provided for delivering the services made it fairly simple to identify the components in the service delivery chain that might affect service delivery to a particular customer. Knowing the likely sources of service problems made it fairly simple to test the appropriate components and isolate the source of a problem.
Today the delivery of more and more telecommunications and broadcast services is converging on IP as the preferred transport layer. The convergence on IP decouples the services from the underlying access and transport networks. The result is a multi-service, multi-domain network where the services themselves are substantially independent of the physical transport layer. FIG. 2 illustrates the convergence on IP as the preferred transport layer. As opposed to the proprietary vertically integrated networks of the past, the new service model defines broad horizontal layers. Open protocols and APIs provide the operational interfaces between layers, with clear separation of access, transport, and services. Thus, the services layer 30 represents any and all services that can be delivered digitally over a network, including, but not limited to voice 24, data 26, and video 28. The transport and distribution layer 32 encompasses the IP layer 30 and the physical distribution layer 36. Through the use of open protocols and APIs all services can be packaged for transport via IP. The IP packaged data may be carried by virtually any and all physical network technologies.
The convergence on IP as the common transport layer for delivering multiple services to customers adds significant complexity to the service delivery chain. Today value added services (VAS) are based on complex network architectures and operational platforms. Portions of the service delivery chain may be, and likely are, outside the control of the service providers themselves. In these cases service providers must rely on networks and hardware provided and maintained by others to deliver their services. The decoupling of the services from the underlying access and transport system makes diagnosing and correcting service problems a much more difficult task than it was in the standalone service delivery platforms of the past.
To illustrate the complexity of today's service delivery platforms, consider the basic DSL service architecture 40 shown in FIG. 3. On the left, an Asymmetric Digital Subscriber Line (ADSL) 52, or a Symmetrical High-Speed Digital Subscriber Line (SHDL) 54 provides a digital connection to a customer's home or business. The DSL connection provides access to the broader IP network or internet via a Network Application Server (NAS) 42. The customer's DSL line (ADSL or SHDL) connects to a first, local DSL access multiplexer (DSLAM) 50. The local DSLAM 50 serves a limited number of customers in a small geographical region. The local DSLAM 50 connects to a remote DSLAM 48 which serves a plurality of local DSLAMS. The remote DSLAM 48 connects to an ATM network 45 via a first BPX switch 46. The NAS 42 connects to a second BPX switch 44 elsewhere in the ATM network 45. There are likely additional BPX switches in the ATM network 45. However, from the point of view of delivering internet access to the customer at the end of the ADSL line 52 via NAS 42, BPX switches 44 and 46 serve as the entry and exit points to the ATM network 45 and any other BPX switches within the ATM network are not relevant to the service delivery chain. The DSL technology is currently evolving introducing the possibility to deliver current and new services through different infrastructures using IP DSLAMs connected through Ethernet interface to GBE (Gigabit Ethernet) or MANs (Metropolitan Area Network).
The service delivery chain becomes more complicated when the Customer Premises Equipment (CPE) is taken into account. The DSL service depicted in FIG. 3 requires at minimum a DSL modem at the customer's premises. Local area networks, WI-FL Routers, and other CPE can further complicate the service delivery picture. FIG. 4 shows a not atypical customer premises arrangement 60. ADSL Line 62 enters the customer's premises via a network interface device 64. A splitter 66 separates voice and data, connecting the voice signal to a standard telephone set 72 via a first wall jack 68 and connecting data signal to a DSL modem 74 via a second wall jack 70. A local area network hub 76 connects a plurality of computers 78, 80, 82 to the DSL modem 74. Thus each computer has access to the DSL line via the LAN. In addition to the network components described with regard to FIG. 3, the DSL modem 74 and the LAN HUB 76 must also be operating and configured properly in order for users at computers 78, 80, 82 to received services over the DSL line 62. Thus, if these components are not operating properly or are not configured properly, the CPE domain can provide another source of service problems.
The service delivery chain becomes even more complicated with the increased complexity of the services delivered. For example, FIG. 5 shows a typical architecture for voice over network (VoN) service. Tracking down a service problem for an individual customer in this environment can be a very complicated task. As can be seen, the VoN service requires the interaction of multiple network domains, including multiple network elements and service components. Furthermore, the service is provided to multiple customers, at different location, having different connections and having different CPE.
The VoN architecture 100 is divided between the VoN or service layer 102, the transport layer 104, and the CPE layer 106. Starting with the CPE layer 106, a number of different client configurations are shown. The different client configurations will depend mainly on the type of access to the transport layer, the available bandwidth, and other factors.
Client 108 includes a local area network 114, one or more VoN telephone devices 116, and a plurality of user computers 118. A Customer Edge 120 interfaces with a Provider Edge in the transport layer 104, providing access to a virtual private network (VPN) 140. VPN 140 is based on multi-protocol label switching (MPLS). The VPN 140 accesses the broader IP network via NAS 154.
The Client arrangement 110 includes a local area network 126 and a plurality of VoN telephone devices 122. A Customer Edge 124 provides the interface to an IP Edge Network 142. The IP Edge Network 142 provides access to the broader IP network 148.
Client 112 includes a plurality of traditional telephone devices 128, an Access Gateway, and a Customer Edge 132. The Access Gateway 130 and the Customer Edge 132 interface with DSLAM 158 via a digital subscriber line.
Also shown in the customer layer 106 are a traditional PBX 134 and a traditional telephone device 136. In the system shown, the PBX 134 and the traditional telephone device 136 may participate in telephone calls with customers employing the VoN service. However, the PBX 134 and telephone device 136 operate on a traditional public switched telephone network 146 and are not themselves amenable to VoN service.
The transport layer 104 includes the VPN 140, the IP Edge network 142, the ADSL network 144, the PSTN 146, the IP network 148, and a backbone network transit level 150 for traditional voice service, as well as the interface components therebetween. For example, the VPN 140 interfaces with the IP network 148 via NAS, 154. The ADSL network interfaces with the IP network 148 via NAS 156. The PSTN interfaces with the backbone network of backbone transit level (BB-TL) 150. The IP network interfaces with the BB-TL network via a media gateway (MG) 162.
The VoN service layer 102 includes a user profile database 172, Packet IN application server 174 that includes service logic and user profile data, one or more SIP Servers and Softswitches 166 for interfacing with the PSTN 146 via the BB-TL 150.
In this example, the service delivery chain includes all of the network elements involved in delivering VoN service to the end customer. For example, to deliver VoN service to customer 112 the service delivery chain includes the Sip Server and Softswitch 170, the switch 166, the media gateway 162, the NAS 156, DSLAM 158, and the Access Gateway 130. Additional components within the various network domains such as ATM switches, IP routers, and the like may also comprise part of the service delivery chain. All of these elements must be operating and configured properly to provide VoN service to the customer 112. Of course different networks and different network elements will be part of the service delivery chain delivering VoN service to other customers. Identifying all of the network elements involved in delivering service to a particular customer is a significant task in troubleshooting service delivery problems. Performing tests on all the various equipment comprising service delivery chain and checking configuration data across all of the service delivery domains has been well nigh impossible.
To date there has been no system or procedure for providing comprehensive end-to-end test and diagnostics of services delivered via the IP transport layer with a structured, end-to-end approach. The lack of such systems and procedures adds significantly to the time, effort and expense of troubleshooting service delivery problems.